If several authors have simultaneously produced modified versions of a common document, it can be a painful process to produce a version which incorporates (or intentionally omits) their changes, and—for passages changed by more than one author—synthesizes the proposed changes into a single, readable passage containing their different insights.
Various software attempts to ease this difficulty. For example, Microsoft Word has a ‘compare and merge documents’ tool. Suppose a document contains the sentence “The best method on the market today is a catheter,” amended by one author to “The best method on the market today is a catheter, which sucks” (sucking is indeed among the functions that catheters perform) while another gives “The best method on the market today is a catheter, which does not directly assess volume”. Then, merging the first with the original and then merging the second yields “The best method on the market today is a catheter, which sucks does not directly assess volume”. (No markers indicate where there were pre-merger conflicts, or the sources of the different versions.) This example does not exhaust, but does illustrate, the harmonization tools available to users. A more usable and structured approach is sorely needed.
A more acute version of the harmonization problem arises where the ‘text’ is a computer program, with different members working on different modules. Minor inconsistencies among assumptions applied to different sections can easily crash the entire application, or even prevent it from compiling. This has led to an industry of ‘version control’ software such as (sampling those running under Windows) Visual SourceSafe, ClearCase, abCVS, CWPerforce and Alienbrain. Some programmers can fit themselves into the discipline of using one of these, since they appreciate the logic and learn its elaborate procedures for detailed control. Many more programmers fail the discipline, or resist it. Few non-programmers can even understand the rules.
In “A Method and System for Facilitating the Production of Documents” submitted to USPTO in January 2007 60/884230, the present inventors described a means to compare a set of documents to describe descent among documents, which among other benefits makes clear which versions have already been incorporated, and need not be looked at again. Within this setting, they disclosed an exemplary means of combining changes from among those documents that still need attention. This means presents the user with ‘slips’ across the width of the text, as in Drawing 1, corresponding to Drawing 16 of that application. In the example shown, the buttons 111 and 113 for version authors Marion and Anne have been activated, and hence overlap the text window 101. Since the button 112 for George has not been pressed, it remains disjoint from the window 101, and that user's changes do not appear as slips. The changes represented by the versions from Marion and Anne do appear: colour coding (not shown in this medium) and the tab handle 121 show that it is Anne who has proposed 1635 the deletion of the word “monitoring” and the transfer 131 of the whole sentence that contains it to a different location: Marion's slip (with the tab handle 123) proposes a tightening in situ. The application goes on to describe means by which the user can accept, reject, modify and combine such proposed changes.
The present application discloses a different, column-structured embodiment of the above invention, and applies it also to situations where the descent description there disclosed is unavailable, or not in use. For example, suppose the user Noah has drafted a naval architecture proposal and sent it to Ham, Shem and Japheth for suggestions. Each of them revises it, according to his particular preoccupations and expertise, and return a version to Noah. (If he also circulates it to the others, the resulting proliferation of texts may make descent handling important. We suppose here that only Noah receives the new versions.) They may use Change Tracking software which displays to Noah, in each version, what changes have been made. If the file had gone from Noah to Ham to Shem to Japheth in sequence, and then returned to Noah, he would receive a single file, perhaps with changes colour-coded by author. But Noah had a deadline, and asked them to work in parallel, so he must now harmonize three distinct files.
The technology described in this application concerns the means by which a user may do such harmonization, for any group of sequential files. By this we mean not that the file's 0s and 1s are sequentially stored in the computer's memory (this applies piecewise to all files, by the fundamental digital architecture involved), but that the file or its sections are normally read sequentially by the user: text, musical notation and computer code are all examples of this, though the reader's attention may skip from subsequence to subsequence (paragraph, movement, header code, etc.) in any order. Images and 3D scans, or other 3D constructs, are not sequential files in this sense. Music and video files are sequential, but the technology described in this application applies to them only where they are presented to the user as a modifiable sequence of sequentially organised lines: visually, or for the vision-impaired, by tactile means such as Braille. The means known to us for audible rendering do not lend themselves to its use.